home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Jul 89 / W0009-More on GC-Jul89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.5 KB  |  34 lines  |  [TEXT/GEOL]
  1. Item    5808317                         3-July-89        15:06
  2.  
  3. From:   PASCOE1                         Pascoe, Geoff
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    More on GC
  8.  
  9. Mikel,
  10.  
  11. First- There's a lot of work going on with generation- and/or copy-based
  12. collectors.  In particular, you may want to look into Appel's work ( I think
  13. he's at Brown )- sorry I don't have the references handy.
  14.  
  15. Second- Assignment really isn't the problem at all.  The problem is assigning
  16. older objects to newer objects.  If this happens too often, statistically, then
  17. the efficiency of generation-based collectors deteriorate, since they work best
  18. when newer objects can be collected without refering to older objects.  In Lisp
  19. this is appears to be the case.  Smalltalk, though, probably will not differ
  20. considerably in this respect from languages like Object Pascal.  And, Ungar
  21. appears to get pretty good performance with Smalltalk.
  22.  
  23. Actually, after working on this kind of stuff for a while, I've come to the
  24. conclusion that adding GC to languages like Object Pascal and C/C++/Objective-C
  25. is probably a net loss.  Basically, you pay for the overall languages
  26. inflexibility to get a "a lot" of efficiency, then you take a hit on doing GC
  27. in languages never designed to handle it (it actually costs more in languages
  28. like these.  Then, the programmer has to follow all these special rules to make
  29. sure he doesn't break the collector.  Basically, you get the worst of both
  30. worlds.  It's best to design the language from the bottom-up to handle GC well.
  31.  
  32. Geoff
  33.  
  34.